home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-05
/
xgate200.zip
/
XGATE.DOC
< prev
next >
Wrap
Text File
|
1992-11-22
|
51KB
|
1,651 lines
+------------------------------------------------------+
| |
| |
XGATE 2.0 XGATE 2.0 | |
| |
| |
MHS to SMTP Gateway MHS to SMTP Gateway | |
| |
| |
+------------------------------------------------------+
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Features Features
Seamless Interaction
Rules-Based
No Lookup Tables
Low Administration
Simple Addressing
Intuitive Design
High Reliability
Written to Handle Exceptions
Supports Return Receipts
Automatic Uuencoding / Decoding of File Attachments
Supports MHS 1.1 through 1.5 (SMF-64, 70)
Supports Multiple MHS hosts
Cost Effective / Realistically Priced
i
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Introduction Introduction
XGATE is a reliable, stable, intuitive, and seamless MHS to SMTP
gateway. For its inexpensive registration fee, it also gives you the
best power-to-dollar ratio of any MHS to SMTP gateway available. Most
other MHS to SMTP gateways start at $2,500+, are more cumbersome to
setup, more awkward to use, and less adept at doing the job. In
addition, they usually want more money for each additional MHS host
they might route mail for - or for each user. In a way this seems
almost as ridiculously greedy as if Dos cost more money for each file
stored on a disk.
XGATE reliably bridges the broad worlds of MHS and SMTP with a simple
addressing scheme that requires no routing tables, alias tables, user
name tables, or any other type of configuration maintenance. Once
XGATE is installed and running, new users on both sides have immediate
E-Mail access to users on the other side.
XGATE will route mail for any number of MHS hubs. Since the address
SMTP users use to send mail to MHS users optionally allows the MHS
host name to be specified, XGATE will simply pass the fully qualified
address through to the MHS host its attached to.
XGATE can be run with two different types of SMTP agents:
XSMTP - a high-performance internally multi-tasking add-on module
which uses the PC/TCP kernel from FTP Software.
Charon - a freely copyable SMTP gateway from Clarkson University.
Dave Frailey
DAC Micro Systems
Voice: 800-776-1322
Voice: 805-264-1700
BBS: 805-264-1219
ii
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Shareware Concept (the legal business) Shareware Concept (the legal business)
XGATE (including XSMTP) is not, nor has ever been, public domain or
free software. XGATE is distributed under the User Supported software
concept (Shareware). Non-registered users are granted a limited
license to use XGATE for a trial period not to exceed 45 days in order
to determine if it suits their needs. Any other use of XGATE, or use
past this period, requires registration. All users are granted a
limited license to copy XGATE only for the purpose of allowing others
to try it, subject to the above restrictions as well as these: 1)
XGATE must be distributed in absolutely unmodified form, including ALL
program files, documentation files, and other files. 2) XGATE may not
be included with any other product for any reason whatsoever without a
license from DAC Micro Systems. 3) No charge or payment may be levied
or accepted for XGATE (except that recovered for media and operating
costs).
Bulletin Board system operators may post XGATE on their BBS for
downloading without written permission only if the above conditions
are met, and only if no special fee is necessary to access the XGATE
files (a general fee to access the BBS is acceptable).
The unregistered (shareware) version of XGATE automatically tracks how
many days have passed since the shareware trial period started.
During the first 45 days it will work in a fully functional fashion,
as if it were registered. When 45 days expire and you are still using
the unregistered version, XGATE will start inserting a warning line in
each message that indicates the shareware trial period has expired.
Registering XGATE allows you to use this product after the trial
period expires for an indefinite period of time. Registered XGATE
users will also get mailed notifications when significant updates are
available. More importantly though, registered users know they are
helping to ensure that high-quality software like XGATE can continue
to be developed and distributed in this low-cost manner. For more
information on ordering, refer to the REGISTER.DOC text file included
with this package.
All DAC Micro Systems products are trademarks or registered trademarks
of DAC Micro Systems. Other brand and product names are trademarks or
registered trademarks of their respective holders.
Acknowledgments Acknowledgments
Special thanks to Steve Glick of Dallas County Community College
District for plenty of valuable beta testing help.
iii
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Contents Contents
FEATURES.......................................................I
INTRODUCTION..................................................II
REQUIREMENTS...................................................1
Memory......................................................1
LIMITATIONS....................................................2
CONCEPT OF OPERATION...........................................2
ADDRESSING.....................................................3
SMTP Addressing.............................................3
MHS Addressing..............................................3
The Default SMTP Host.......................................4
OPTIONS........................................................6
Uuencoding..................................................6
Return Receipts.............................................6
Postmaster..................................................8
INSTALLATION...................................................9
Adding a gateway name in MHS...............................10
Variables in XGATE.CFG.....................................11
Using XSETUP...............................................19
iv
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Requirements Requirements
The requirements for XGATE change somewhat depending on which SMTP
agent it is running with.
XGATE always requires its own PC, one that is connected with IPX to
your Novell network. If XGATE is running with the XSMTP add-on
module, the SMTP mailer becomes a background function of XGATE and
runs within the same computer. If XGATE is running with Charon as the
SMTP mailer, a separate computer is needed on which to run Charon.
Documentation on the particulars of each is included in separate
files.
XGATE is written 100% in tight and efficient assembly language. But
even as such - if you are running XGATE with the XSMTP module, the
memory requirements and CPU requirements are a bit higher than if it
is running with Charon as the SMTP mailer.
When XSMTP is the SMTP mailer running as a background function in
XGATE's computer, the computer running XGATE will need a full 640k of
memory and having expanded memory (LIM/EMS) 4.0 will definitely help.
When Charon is the SMTP mailer running on a different computer, XGATE
will do just about as well on a 4Mhz XT as it will on a 66Mhz 486, and
only requires approximately 384k of free memory.
XGATE automatically adjusts to a color or monochrome monitor.
XGATE should work fine with versions of MHS as old as 1.1 (SMF-64).
It automatically detects and uses capabilities in MHS versions as new
as 1.5 (SMF-70).
Memory Memory
XGATE automatically detects and uses expanded memory (LIM/EMS) if its
version 4.0 or greater. You'll probably never come close to having a
problem with free memory if at least 256k of expanded memory is
available.
1
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Limitations Limitations
XGATE's messaging limitations are more those of MHS than XGATE. XGATE
can handle a message of unlimited length. The MHS limit is 64k (ver
1.5) for body text.
XGATE can handle an unlimited number of file attachments and
automatically uuencode them into an SMTP message. It can also do the
reverse with inbound SMTP messages and decode them to multiple MHS
attachments. MHS 1.1 however, can only handle one attachment (in this
case XGATE only decodes the first file and leaves the rest uuencoded
in the message body). MHS 1.5 can handle 64 file attachments, and
XGATE will automatically decode and create attachments for as many
uuencode blocks that exist in the message body text.
Concept of Operation Concept of Operation
How does it work? Its not really that complicated.... When run with
XSMTP or Charon as the SMTP mailer XGATE takes full advantage of
Novell's Queue Services API. On a configurable basis XGATE scans the
MHS outbound directory for new mail, converts anything it finds and
posts it in the SMTP_OUT job queue for the SMTP mailer to handle. In
the same scan cycle it also checks the SMTP_IN job queue, converts any
messages in it and posts them in the MHS inbound directory for MHS to
route.
XGATE uses a "clean-cut" approach to doing business with Novell. When
initially run XGATE logs itself in as a job server and attaches to
both the SMTP_IN and SMTP_OUT job queues. Anything in the SMTP_IN
queue is considered inbound and likewise anything in the SMTP_OUT
queue is considered outbound. When XGATE is run with Charon, the
XCHARON driver running behind Charon forces it to comply with this
simplistic approach. When XGATE is run with XSMTP, more sophisticated
queue services are utilized to rotate and reschedule queue jobs.
All of this stuff about Novell job servers, job queues, and the
appropriate privileges for each, are installed automatically in one
easy step using XGATE's setup program (XSETUP).
2
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
ADDRESSING ADDRESSING
SMTP Addressing SMTP Addressing
So how does a SMTP user send mail to a MHS user? Rather easily. If
the fully qualified SMTP host name for XGATE is called
"charon.myorg.com", users on SMTP simply send mail to:
joe@charon.myorg.com
If you have multiple MHS hosts, and the message is intended for a user
not on the MHS host connected to the XGATE gateway, SMTP users can
include the user's MHS host after the user name as follows:
joe.mhs1@charon.myorg.com
If the destination MHS user is on the same host as the XGATE gateway,
or if MHS is set up to do multi-host workgroups, this should not be
necessary.
If a MHS user's application name needs to be specified (normally it
doesn't since MHS will drop it in their default application), it can
also be included in the address by prefixing it with a percent sign.
For example:
joe%pmail.mhs1@charon.myorg.com
MHS Addressing MHS Addressing
Under MHS you define a gateway name for XGATE to use. The name of the
gateway is akin to the name of another MHS hub. When MHS users send
mail through XGATE, they do it the same way as if they are addressing
a message to a user on another MHS hub, except that "gateway"
information (the actual SMTP address) usually needs to be provided
within curly braces. How you address mail to users on another host
(or gateway) tends to vary between different e-mail applications (user
agents) that run on top of MHS.
The native MHS syntax is:
user . application @ host {gateway_parameters}
3
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
After-market E-mail applications sometimes transform this syntax into
a different form more to their liking. For instance, with DaVinci
eMail Ver 1.7 you would send mail as:
host "gateway_parameters" [:user]
When MHS mail is sent through the XGATE gateway, XGATE normally pays
no attention to the user name unless the gateway parameters are not
given. (It never pays any attention to an application name if
specified.)
In order to get the message to XGATE for conversion, a user must
specify XGATE's gateway name. The actual SMTP address of the
recipient is specified in the gateway parameters. For example, if
your MHS gateway name for XGATE is called SMTP, and a user wanted to
send a message to "joe@hisorg.com", in the native MHS syntax they
would send the message as:
@smtp {joe@hisorg.com}
Note: Some MHS E-Mail applications won't like not having a user name
specified before XGATE's gateway name, in which case a dummy user name
before the gateway name will be necessary. For example:
email @ smtp {joe@hisorg.com}
If your e-mail application is DaVinci ver 1.7, you would send the
message as:
smtp"joe@hisorg.com"
If the sending MHS application does accept an address without a user
name specified, an additional side affect is that when MHS routes the
message, you won't see any user name on the routing activities screen.
To have it be more informative, you could fib to your users and tell
them that the SMTP user name is needed in both locations:
joe @ smtp {joe@hisorg.com}
The Default SMTP Host The Default SMTP Host
In XGATE's configuration you can define a default SMTP host. When
XGATE processes a message that does not contain a host name in the
gateway parameters, XGATE automatically appends the name of the
default host to the SMTP address.
4
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
For example, if the default SMTP host is set to "hisorg.com", and you
wanted to send a message to "joe@hisorg.com", all you have to say when
you address the MHS message is:
@smtp {joe}
This can be carried a step further if the recipient user's name is
eight characters or less because XGATE automatically uses the MHS user
name if no gateway parameters are given. For example:
joe @ smtp
5
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Options Options
Uuencoding Uuencoding
If the "uuencode=" option in XGATE.CFG is enabled (or not specified -
the default is enabled), XGATE will automatically uuencode and decode
MHS file attachments.
When uuencoding is on, each message received from SMTP is scanned for
uuencoded files. The scanning algorithm is very rigid about assuming
the presence of a uuencode block. If any part of the uuencoded block
doesn't conform to the specification, uuencode scanning of the SMTP
message is abandoned and the message body is passed through untouched.
If you are running on MHS 1.5 or greater, multiple uuencoded files may
be passed in a single SMTP message and they'll be decoded into
separate attachments. If you are running a version of MHS older than
1.5, only the uuencoded file is decoded to an attachment. Any
subsequent uuencoded files in the same message will remain in the body
text of the message.
When a block of uuencoded text is decoded from an inbound SMTP
message, the uuencoded block is removed from the message text, but the
lines preceding and following the block remain intact.
When an outbound MHS message contains an attachment, it is
automatically uuencoded. If running on MHS 1.5 or greater and
multiple attachments are present, multiple uuencode blocks are built
within the outgoing SMTP message.
XGATE has no internal limitations on the size of uuencoded files.
Return Receipts Return Receipts
XGATE can be configured to always ask MHS to generate return receipts
when incoming SMTP mail is read by the MHS user, by including the
following statement in XGATE.CFG:
smtp_receipts=y
6
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
But this switch can only be globally on or off for all inbound SMTP
mail. If this switch is disabled, two other methods of getting a
return receipt are still available:
1) SMTP users can ask for a return receipt by embedding a flag in
the address of the message, which produces the same affect on a
case-by-case basis.
Normally, a SMTP user addresses a MHS user as follows:
user.mhshost@gateway
However, an additional "/r" can be appended after the mhshost
and XGATE will then ask MHS to generate a return receipt. For
example:
user.mhshost/r@gateway
2) XGATE always sets the MHS return receipt flag if an inbound
SMTP message has a "Return-Receipt-To:" header field.
For mail going from MHS to SMTP, return receipts are a little more
convoluted.
XGATE.CFG has an option, use_mhs_ret_rcpts, which controls whether
XGATE will pay any attention to whether an MHS user asked for a return
receipt. SMTP was never designed with return receipts in mind though.
Some mailers recognize the "Return-Receipt-To" header field and some
don't. If a mailer recognizes this field, it usually generates the
receipt at time of delivery - not time of reading. If you enable the
"use_mhs_ret_rcpts" flag in XGATE.CFG, XGATE will add a "Return-
Receipt-To" field in outgoing SMTP headers when MHS messages ask for a
return receipt. This option is disabled by default since receipts
generated by this header field could be misleading to an MHS user who
would expect it to mean a time-of-reading receipt.
Another option if the XGATE.CFG use_mhs_ret_rcpts field is disabled is
that MHS users can also embed a flag in the SMTP address which will
cause XGATE to include the "Return-Receipt-To" field in the SMTP
header.
Normally, a MHS user addresses a SMTP user as follows:
user @ gateway {username@smtphost}
However, an additional "/r" can be appended after the username in
the SMTP address and XGATE will then include the "Return-Teceipt-
To" field in the outgoing SMTP message. For example:
7
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
user @ gateway {username/r@smtphost}
Postmaster Postmaster
XGATE Automatically re-addresses inbound SMTP mail sent to
"Postmaster" to the MHS administrator. When it does so, the first
line of the body will include a comment from XGATE indicating that the
message was originally addressed to the postmaster.
When MHS generates an error notification from -Maiser- (where did they
get that name?), XGATE sends the SMTP message as being from
Postmaster.
8
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Installation Installation
The recommended place to install XGATE is on the local hard drive of
the PC from which it will run. You can try installing XGATE on a
network volume, but when XGATE terminates it will automatically log
itself out from the file server, and the only network drive visible at
that point is the SYS:LOGIN directory - which is probably not where
you would have installed XGATE.
If you really want to run XGATE from a file server volume, whatever
process which runs XGATE would have to be capable of logging in under
a temporary ID (with read privileges to that directory), map a drive
to the directory, change directories, and then run XGATE.
Before XGATE logs in as a job server, it first reads all overlays and
configuration files. When you run XGATE the current directory must be
where XGATE's overlays and configuration file (XGATE.CFG) are located.
If you did install XGATE on a file server volume, normal users do not
need any disk privileges to XGATE's directory.
The generic installation of XGATE consists of three steps:
1. Adding a gateway name in MHS
2. Editing XGATE's configuration file, XGATE.CFG
3. Using XSETUP to build the Novell job servers and queues
After you accomplish these steps, you must then refer to the
installation instructions for either XSMTP or Charon, depending on
which one you're using as XGATE's SMTP agent.
9
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Adding a gateway name in MHS Adding a gateway name in MHS
When you tell MHS to add a gateway name, it automatically builds the
appropriate directory structure for the gateway under
mv\MHS\MAIL\GATES. If you already know how to do this, go ahead and
add the gateway name (configure the gateway version as either 64 or
70) - there's nothing more that needs to be done with MHS and you can
skip ahead to editing the variables in XGATE.CFG. XGATE doesn't use
the normal INPOST or OUTPOST executables, it only needs the directory
structure.
To add the gateway name under MHS that XGATE will use, you must log
into MHS as the MHS administrator and run the Directory Manager.
Under the Directory Manager, you then select "routes to workgroups,
hosts, and gateways" and from there, pick "Add entry" and then pick
"Define a gateway".
What you enter for the "Host name:" is the most significant item of
information. You might want to keep it short and easy to type. This
is the name MHS users will type when they send mail through XGATE (you
could of course define another hub which routes via this name if you
want to alias it down to a shorter name). Whatever you type for the
"Host name:" - remember it and write it down. You will also need to
enter it into XGATE's configuration file.
What you enter for the "Description:" is purely discretionary. XGATE
doesn't use it.
Under "Gateway Version:" you can enter either 64 or 70. This tells
MHS what level of the SMF language the gateway understands. If set to
70, messages with more than one XGATE recipient will be kept in one
file for fan-out by the gateway.
Under "Gateway Commands:" don't enter anything. A lot of MHS gateway
programs are run directly within MHS and these are the commands that
would be passed to the gateway program when executed. Since XGATE
runs on a separate PC, gateway commands should be left blank.
So all we're really doing is just using MHS to build a new gateway
name in its host table and creating the corresponding MHS directory
structure. Nothing more. The first time XGATE runs it will
automatically build some additional directories under its gateway
subdirectory in MHS. But you don't need to worry about doing it
yourself.
10
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Variables in XGATE.CFG Variables in XGATE.CFG
XGATE is configured by editing a text file called XGATE.CFG with
whatever text editor suits your fancy.
A sample XGATE configuration file is included with this package.
The format (syntax) of the XGATE.CFG file is very loose. You can use
spaces, tabs, and the equals sign to delimit variable names from their
values.
What follows are the descriptions of variables which are generic to
XGATE (needed for both XSMTP or Charon modes), listed in the order
they appear in the XGATE.CFG configuration file.
Variables specific to XSMTP (applicable only if you are using it
instead of Charon) are described in XSMTP's separate documentation.
If you aren't using XSMTP, XGATE will ignore the XSMTP variables.
mhs_path= mhs_path=
This variable tells XGATE what directory contains MHS. This path
is normally entered using a Novell volume name, not a Dos drive
letter. For instance, if MHS is installed in the root directory
of SYS: (i.e. the path to the MHS Mail directory is SYS:MHS\MAIL),
you would enter "mhs_path=SYS:" (without the quotes).
mhs_gateway_name= mhs_gateway_name=
This variable tells XGATE what gateway name to scan under MHS, and
is also used to build the return address in outgoing SMTP mail.
It should contain the same name used when you added the gateway
name under MHS.
mhs_admin_errors= mhs_admin_errors=
This variable tells XGATE whether or not to send the MHS
administrator copies of various errors (such as routing or non-
delivery) as a message. The possible answers are either Yes or
No.
11
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
mhs_administrator= mhs_administrator=
This variable overrides XGATE's automatic determination of the MHS
administrator. Normally XGATE will determine who the MHS
administrator is by reading MHS's NETDIR.TAB file. It can be
convenient to override who that user is if a different person
administers the SMTP gateway than who the MHS administrator is.
The address entered is expressed in native MHS syntax (i.e.
mhs_administrator=joe@mhs1).
mhs_default_host= mhs_default_host=
This variable controls what happens to inbound SMTP mail when it
does not contain an MHS host name. If this variable is omitted or
left blank, XGATE will route the message to the local MHS hub. If
this variable is set, inbound SMTP mail that doesn't contain a MHS
hub (host) name will be routed to the value given.
This variable is most often used to send inbound SMTP mail without
an MHS host name to a workgroup's name instead of the local host's
name.
use_mhs_total_fields= use_mhs_total_fields=
This variable enables an effect similar to the
"include_smtp_fields" option above, except that it works a little
more cleanly provided your MHS software recognizes the SMF-70
"Total-to:" and "Total-Copies-to:" header fields. If this option
is enabled, XGATE will write the "Total-to:" and "Total-Copies-
to:" MHS header fields with a complete list of their respective
recipients. This keeps the information out of the body text and
possibly allows replies to go to all recipients, but only if your
MHS E-Mail application works properly with these fields. Possible
values are either Yes or No.
You probably don't want to enable this option, and
"include_smtp_fields" at the same time.
include_header= include_header=
This variable controls whether the entire header of inbound SMTP
messages is passed through in the body text of MHS messages built.
Its allowable values are either Yes or No.
12
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
include_smtp_fields= include_smtp_fields=
This variable allows some of the SMTP header fields to pass
through at the beginning of the body in the MHS message.
Sometimes these fields can provide a lot of valuable information
to the MHS user which might otherwise be hidden depending on the
particular MHS E-Mail software in use. For instance, if a message
had multiple recipients (specified by the SMTP To: header field),
but the MHS E-Mail software displays the MHS "Send-To:" field
instead, the MHS recipient won't see the complete list of
recipients.
This variable has the following format:
include_smtp_fields=[T][F][C][R]
Each flag enables the following SMTP header fields:
T - To:
F - From:
C - Cc:
R - Reply-To:
smtp_gateway_name= smtp_gateway_name=
This is the fully qualified host name which you will configure
Charon to run as. It is used to build the reply address in
outgoing SMTP mail.
smtp_default_host= smtp_default_host=
This is an optional fully qualified host name which you can use to
have mail automatically sent to if the MHS user didn't specify a
destination SMTP host. This doesn't have to have anything to do
with the relay host you will configure Charon to send all outgoing
SMTP mail to.
13
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
smtp_user_suffix= smtp_user_suffix=
This is an optional field which normally has no value. If for
some reason you need some additional text inserted in a reply
address between the user's name and the smtp_gateway_name, this
field will do that. XGATE automatically formats the reply address
of an outgoing SMTP message as "user.mhshost@smtp_gateway_name".
Any text entered by this variable will be inserted between
".mhshost" and "@smtp_gateway_name". This variable is only used
when building the reply address of an outgoing SMTP message.
smtp_timezone= smtp_timezone=
This variable controls what text XGATE appends after the time a
message was entered. Normally this is a value such as PST, EST,
etc... This variable is only used when building the reply address
of an outgoing SMTP message, and only if the date field did not
use a Universal Time Coordinate.
smtp_exclude_mhs_hub= smtp_exclude_mhs_hub=
This variable controls whether outgoing SMTP messages will include
the name of the MHS hub from which they originated in the return
address.
In a single MHS hub environment where XGATE and the only MHS hub
are on the same file server, it may not be considered necessary
for inbound SMTP messages to include the name of the MHS hub in
the reply address, since messages received from SMTP without an
MHS hub name are normally routed to the MHS hub from which XGATE
runs (unless overridden with MHS_DEFAULT_HOST).
Answering yes to this variable might reduce some confusion if you
plan to tell SMTP users that MHS users are addressed as
"user@smtphost" instead of "user.mhshub@smtphost", since they then
won't get messages with the reply address showing the MHS hub as
in the second example.
14
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
smtp_receipts= smtp_receipts=
This variable controls whether all messages are flagged to produce
a return receipt (back to a SMTP user) when XGATE converts a SMTP
message to MHS. Possible answers are only Yes or No. Normally
this variable isn't turned on. There is a method in XGATE's
addressing syntax however for SMTP users to flag they want a
return receipt based on how they address the destination MHS user.
This was described previously under "Return Receipts". As best I
can determine, there is no standard way to cause SMTP user agents
to produce time-of-reading return receipts based on something
inserted in the SMTP message header. If I am incorrect please let
me know.
use_mhs_ret_rcpt= use_mhs_ret_rcpt=
This variable controls whether XGATE will pay any attention to
whether an outbound MHS message has the return receipt flag set.
If this variable is enabled and an MHS message requests a return
receipt, a "Return-Receipt-To:" header field is inserted in the
SMTP header built. In most cases however, any notification
returned is only a delivery notification from the SMTP mailer,
not a time-of-reading notification. If most MHS users on your
system default to having return receipts enabled, it may not be
desirable to have this option enabled. It is off by default.
uuencode= uuencode=
This variable controls whether XGATE will automatically uuencode
files attached to MHS messages, and whether it will automatically
scan inbound SMTP messages for a block of uuencoded text.
Possible answers are either Yes or No.
decode_header= decode_header=
This variable is provided to help trigger automatic uudecoding of
encoded MHS file attachments when they reach a remote SMTP user.
A lot of SMTP user agents won't automatically scan for uuencode
blocks unless they see a header field in the SMTP message which
makes them think the message might have a block of uuencode text.
When one or more of these variables are defined in XGATE.CFG,
XGATE will automatically insert all of them in the header of the
SMTP message when it uuencodes a MHS file attachment.
15
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
The best way to determine whether this field is needed, and what
text to use if so, is to scrutinize the header generated by the
SMTP user agent in question when it itself uuencodes a file
attachment.
If the name of the attached file is needed in the SMTP header,
embedding a %fn in the variable's definition will expand into the
real-time name of the file(s) when the message is built.
For example:
decode_header=Next-Attachment: %fn
decode_header=Content-Type: x-uuencode-apple-single
The first example is designed to trip automatic decoding on NEXT
computers, and the second for Apple computers running Microsoft
Mail. A little experimentation may be necessary to determine
whether a remote SMTP user agent can be tricked into automatically
decoding a uuencoded block, and what the proper values are.
scrap_mhs_attach= scrap_mhs_attach=
This variable allows you to specify filenames which are
automatically scrapped (discarded) if they appear as an MHS
attachment (vice uuencoding them). This is useful with some E-
Mail applications which like to always add an attachment
containing formatting information (such as Beyond's Windows
product) that has no useful purpose if sent across an SMTP
gateway. This variable can be defined more than once.
For example:
scrap_mhs_attach=*BEYOND* ;Scrap Beyond's attachs
scan_frequency= scan_frequency=
This variable controls how often XGATE will scan for new mail in
seconds. XGATE is very efficient about doing this, so a value
between 10 and 20 seconds would not impose much of impact on
network traffic or file server utilization.
16
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
black_and_white= black_and_white=
This variable tells XGATE whether to operate in black and white
mode. This could be useful when you have a monitor that displays
shades of green (or whatever) attached to a color video card.
mute= mute=
This variable tells XGATE whether or not the speaker is muted when
errors are displayed. Possible answers are either Yes or No.
screen_save= screen_save=
This variable sets the number of minutes after which XGATE will
blank the screen if no activity has occurred. A value of zero
disables the screen saver. The screen is automatically un-blanked
when new activity occurs.
inbound_log= inbound_log=
If this variable is given, a complete path and filename must be
specified. XGATE will then write a single-line entry in the file
for each inbound SMTP message received. If the path points to a
server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant
Additional Privs" option in XSETUP must be used to give the XGATE
job server privileges to the directory.
outbound_log= outbound_log=
If this variable is given, a complete path and filename must be
specified. XGATE will then write a single-line entry in the file
for each outbound SMTP message received. If the path points to a
server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant
Additional Privs" option in XSETUP must be used to give the XGATE
job server privileges to the directory.
17
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
error_log= error_log=
If this variable is given, a complete path and filename must be
specified. XGATE will then write a single-line entry in the file
for each error or warning message encountered. If the path points
to a server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant
Additional Privs" option in XSETUP must be used to give the XGATE
job server privileges to the directory.
18
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Using XSETUP Using XSETUP
After you've created the MHS gateway name in MHS and edited XGATE's
configuration file (XGATE.CFG), the last step to generically
configuring XGATE is to use XSETUP to build the Novell job servers and
job queues which XGATE uses.
Before running XSETUP you must first log in as a supervisor
equivalent. If you are initially installing XGATE, simply pick the
"Create Server & Queues" option and XSETUP will do the rest.
XSETUP can also be used to remove the job servers and job queues, or
to grant additional privileges to other network directories for the
XGATE job server, if you want XGATE to write log files to a network
drive.
When you are finished using XSETUP (it doesn't take long), the generic
portion of XGATE's installation is complete. You next have to
configure either XSMTP or Charon, depending on which you will be
using. Their installation and configuration is documented in separate
files under their own names.
Create Server & Queues Create Server & Queues
This option automatically builds and configures all of the Novell-
related details XGATE needs. After you pick it, XSETUP will ask
you for the Novell path to the MHS directory. If you entered
"SYS:" in XGATE's configuration, you would enter the same here.
After that, the rest is automatic.
During the "Create Server & Queues" process, XSETUP will attempt
to create a directory on SYS: called CHARON and grant RWCEMF
privileges to that directory for the job server that XCharon will
log in as. This directory is intended to provide a place where
Charon has full disk privileges, mainly for writing log files. If
you are using XGATE's XSMTP module instead of Charon, you can
delete the SYS:CHARON directory afterwards.
Remove Server & Queues Remove Server & Queues
This option completely removes the job servers and job queues that
"Create Server & Queues" created in the Novell Bindery.
19
XGATE - MHS to SMTP Gateway
----------------------------------------------------------------------
Grant Additional Privs Grant Additional Privs
This option allows you to grant the XGATE job server RWCEMF
privileges to additional network directories. Currently the only
reason this is needed is if you want XGATE to write its log files
to a network directory.
20